1. Field of the Invention
Embodiments of the present invention relate generally to product upgrade techniques and more specifically to a method and system for upgrading software in a computing device.
2. Description of the Related Art
Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
The consumer electronics marketplace is known to be fiercely competitive. Because of the tremendous and constant pressure to bring new products to the market at a faster pace and also at lower prices, these product offerings are often fraught with reliability issues due to sloppy quality assurance processes, deployment of transient technologies, and buggy designs. Moreover, since consumer electronic products tend to have a user life that lasts several years, these products typically need to go through multiple upgrades to address the reliability issues. With most of the consumer electronic products come equipped with flash memories, a typical upgrade process involves downloading a software image from a source system on a network and loading the software image into the flash memories of the target products without replacing the target products.
To further demonstrate the upgrade process, FIG. 1A is a conceptual diagram of some components in a computing device 100 that are involved in a conventional upgrade process 150, and FIG. 1B is a flowchart illustrating the method steps in the conventional upgrade process 150. The components that are involved include a CPU core 102, a flash memory 104, and a system memory 106. The computing device 100 communicates with a source system 110 via a network 108. When the CPU core 102 comes out of a reset condition, it fetches the instruction from a predetermined address 112 in step 154. This predetermined address 112 is commonly referred to as a “reset vector.” Executing the instruction then triggers the retrieval of a software image 114, often in a compressed form, from the flash memory 104. In step 156, the software image 114 is decompressed and placed in the system memory 106 for further processing. Suppose the software image 114 includes a boot code segment 116 and an application software segment 118, which includes some upgrade code. Under normal operating conditions, the CPU core 102 successfully executes the upgrade code, and the computing device 100 proceeds to request a new software image from the source system 110 via the network 108 in step 158. In step 160, the computing device 100 receives the new software image from the source system 110 and places the image in the system memory 106 for further processing. Lastly, the new software image is placed in the flash memory 104 to overwrite the software image 114 in step 162, and the computing device 100 reboots in step 152 so that the new software image can take effect.
The conventional upgrade process 150 has flaws that may render the computing device 100 non-operational. For example, if an unexpected system failure, such as a power failure, occurs while the new software image is being written into the flash memory 104, then the boot code segment 116 may be corrupted with useless and non-operational code. If the instruction at the reset vector is corrupted, then the computing device 100 cannot complete its reboot sequence and remains in an undefined state. At this point, sellers of the computing device 100 mostly likely need to replace the unit for the customer. Especially in a mass deployment situation, if this irrecoverable failure applies to many of the deployed computing devices, then it significantly reduces the appeal of this product to customers and also places tremendous burden on sellers to replace all the failed units.
As the foregoing illustrates, what is needed in the art is a software upgrade process that is robust and addresses at least the shortcomings of the prior art approaches set forth above.